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Executive  Summary 

Secure  Solutions,  Inc.  was  tasked  by  the  Department  of  the  Navy’s  Space  and 
Naval  Warfare  Systems  Command  (SPAWAR)  to  perform  a  Smaill  Business  Innovation 
Research  (SBIR)  Phase  II  network  security  research  effort  on  the  “Placement  of 
Security  Services  for  Secure  Data  Exchange.” 

A  major  thrust  in  Naval  command  and  control  is  to  securely  interconnect 
networks  for  the  purpose  of  sharing  information  and  Improving  the  survivability  of  the 
overall  network.  To  support  application-level  interoperability  among  command  and 
control  systems  which  use  these  networks,  the  use  of  a  layered  architecture  is 
imperative. 

The  placement  of  security  services  within  the  International  Standards 
Organization  (ISO)  Open  Systems  Interconnection  (OSI)  Reference  Model  (RM),  the 
open  framework  for  a  layered  architecture,  has  always  been  controversial.  The  SBIR 
Phase  I  (Placement  of  Network  Security  Services  for  Secure  Data  Exchange)  effort 
fuifilied  a  need  to  identify  the  security  services  and  mechanisms  that  should  be  provided 
at  each  of  the  layers  with  specific  consideration  for  Naval  applications.  The  following 
table  presents  the  allocation  of  security  services  to  the  OSI  RM  for  Naval  applications 
that  was  developed  as  a  result  of  the  Phase  I  effort. 


Layer 

Service 

1 

2 

3 

4 

S 

6 

7 

Data  Confidentiality 

• 

• 

• 

• 

Data  Integrity 

• 

• 

• 

• 

Authentication 

• 

• 

• 

• 

/Access  Control 

• 

• 

• 

• 

Non-repudiation 

• 

• 

The  Phase  I  made  the  qualitative  observation  that  the  delivery  time  through  a 
secure  relay  (or  secure  front  end)  could  be  improved  (reduced)  if  the  security  protocol  is 
implemented  at  a  lower  layer  within  these  components. 

This  study  (Task  1  of  the  Phase  II  SBIR  effort)  identifies  potential  sources  which 
can  be  used  to  qualitatively  determine  the  improvement  in  delivery  time  through  three 
variations  of  a  local  area  network  (LAN)  internetwork.  The  LAN  internetwork  consists  of 
two  802.3  LANs  interconnected  through  a  backbone  fiber  distributed  data  interface 
(FDDI)  LAN.  Three  different  types  of  secure  relays  are  used  to  interconnect  the  802.3 
LANs  with  the  FDD!  LAN.  They  each  use  different  types  of  security  protocols  at 
different  OSI  layers  —  the  Secure  Data  Exchange  (SDE)  protocol  at  Layer  2;  Security 
Protocol  3  (SP3)  or  the  Network  Layer  Security  Protocol  (NLSP)  at  Layer  3;  and 
Security  Protocol  4  (SP4)  or  the  Transport  Layer  Security  Protocol  (TLSP)  at  Layer  4. 
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1.0  Introduction 

This  report  documents  the  results  of  an  analysis  performed  by  Secure  Solutions 
under  Phase  11  of  a  Small  Business  Innovation  Research  (SBIR)  Program  for  the 
Department  of  the  Navy’s  Space  and  Naval  Warfare  Systems  Command  (SPAWAR) 
under  Contract  Number  N00039-93-C*0099.  This  overall  research  topic  is  entitled 
"Placement  of  Security  Services  for  Secure  Data  Exchange*  (Topic  Number  N91-061). 
This  report  documents  Task  1  of  the  Phase  II  SBIR  effort  and  demonstrates 
quantitatively  how  much  delivery  times  can  be  improved  (reduced)  by  implementing 
security  protocols  at  lower  OSI  layers  in  relays  (or  front  ends).  The  results  of  this  task 
extend  the  qualitative  conclusions  reached  in  Phase  I  and  also  provide  an  input  to  the 
systems  /  security  engineering  process  that  is  used  under  Task  4  of  this  effort  to  define 
Naval  requirements  for  secure  network  products. 

This  introduction  provides  background  for  why  this  effort  was  initiated,  study 
scope,  study  objectives,  the  approach  used  and  recommendations,  and  the  organization 
of  the  report. 

1.1  Background 

Naval  command  and  control  systems  are  hosted  on  shipboard,  shore,  and 
airborne  platforms  and  operate  in  a  variety  of  environments.  Diverse  communications 
networks  are  used  to  support  these  command  and  control  systems.  These  networks 
operate  from  the  Extremely  Low  Frequency  (ELF)  to  Extremely  High  Frequency  (EHF) 
bands  and  employ  both  point-to-point  and  broadcast  transmission  techniques.  A  major 
thrust  in  Naval  command  and  control  is  to  interconnect  these  networks  for  the  purpose 
of  sharing  information  and  improving  the  survivs^ility  of  the  overall  network. 

The  use  of  a  layered  architecture  is  imperative  to  support  application-level 
interoperability  among  command  and  control  systems  which  use  these  networks 
[Copernicus  91].  One  major  framework  for  an  open,  layered  architecture  is  the  7-layer 
International  Standards  Organization  (ISO)  Open  Systems  Interconnection  (OSI) 
Reference  Model  (RM),  as  described  in  ISO  7498  [ISO  84].  The  placement  of  security 
services  within  the  OSI  RM  Is  governed  by  the  OSI  RM  Security  Architecture,  described 
In  ISO  7498-2  [ISO  89A]. 

A  problem  with  the  approach  used  by  ISO  to  place  security  services  within  the 
OSI  layers  is  that  it  did  not  take  into  account  some  of  the  stringent  constraints 
encountered  in  the  Naval  tactical  environment.  For  example.  It  is  critical  that  placement 
choices  be  made  in  a  manner  that  conserves  bandwidth,  supports  real-time 
transmission  requirements,  and  promotes  survivability  and  availability.  These 
evaluation  factors  were  not  considered  by  the  authors  of  ISO  7498-2  in  allocating 
security  senrices  to  the  different  OSI  layers. 

As  a  result,  the  need  to  analyze  the  security  services  that  should  be  provided 
among  the  seven  OSI  layers  for  Naval  applications  was  identified.  This  analysis  was  to 
take  into  account  the  previous  work  in  this  are  performed  by  ISO  and  the  IEEE  802.10 
Standard  for  Interoperable  LAN  Security  (SILS)  committees  (which  allocated  additional 
security  services  to  layer  2  beyond  the  those  already  specified  by  the  OSI  Security 
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Architecture),  as  well  as,  the  associated  impacts  on  Communications  Security 
(COMSEC)  and  Computer  Security  (COMPUSEC)  assurance  criteria,  and  features 
important  to  Navy  missions  such  as  bandwidth  conservation,  delivery  /  response  time, 
survivability  and  reconfigurability.  The  SBIR  Phase  I  research  effort  on  the  Placement 
of  Security  Services  for  Secure  Data  Exchange  was  initiated  under  contract  N00039-92- 
C-0039  to  help  fulfill  this  need. 

This  SBIR  Phase  11  network  security  research  and  development  (R  &  D)  effort 
extends  the  work  of  the  Phase  I  study  by  further  refining  and  validating  the  engineering 
rationale  developed  during  Phase  I,  analyzing  security  service  placement  options  for 
specific  Navy  applications,  analyzing  end-to-end  encryption  and  traffic  flow  security 
options,  conducting  system  engineering  studies  to  define  Naval  mission-specific  security 
needs,  and  developing  Naval  security  product  functional  requirements  specifications  for 
potential  network  security  products. 

One  of  the  factors  considered  during  Phase  I  was  the  determination  of  the 
relative  impact  on  delivery  times  depending  upon  where  the  security  protocols  are 
implement^  within  the  OSi  layered  architecture.  Two  major  conclusions  were  drawn: 

•  Providing  end-to-end  security  services,  as  opposed  to  link  security  services, 
improves  (reduces)  delivery  time,  since  security  encapsulation  /  decapsulation 
functions  are  only  performed  at  the  source  and  destination  host.  When  link 
security  services  are  used,  security  encapsulation  /  decapsulation  functions 
are  performed  repeatedly,  thereby  increasing  the  host-to-host  delivery  time  for 
a  given  network  configuration. 

•  In  some  situations,  it  is  desirable  to  implement  security  services  within  relays 
(or  host  front  ends).  Implementation  of  security  protocols  at  lower  OSI  layers 
in  relays  (or  front  ends)  reduces  the  host-to-host  delivery  time,  since  fewer 
headers  are  processed  within  the  relays  /  front  ends. 

Task  1  of  the  Phase  II  SBIR  effort  expands  upon  the  second  conclusion  by 
defining  quantitatively  the  improvement  (reduction)  of  delivery  times  when  security 
protocols  are  implemented  at  lower  OSI  layers  in  relays  (or  front  ends). 
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12  Scope 

There  are  a  number  of  factors  to  consider  in  determining  the  layers  at  which 
security  protocols  should  be  implemented  within  the  OSI  RM  for  Naval  applications. 
This  effort  addresses  one  of  these  factors  —  delivery  time.  Its  primary  objective  is  to 
determine  if  the  layer  at  which  a  security  protocol  is  placed  has  a  significant  influence  on 
delivery  time  in  quantitative  terms.  The  results  of  this  study  provide  one  input  to  the 
system  /  security  engineering  process  used  in  Task  4  of  this  SBIR  effort.  Task  4 
establishes  requirements  for  network  security  products  for  the  Navy.  In  Task  4,  a 
variety  of  factors  are  considered  to  select  the  best  OSI  layers  for  implementing  security 
protocols. 

The  specific  network  configuration  used  as  the  basis  for  this  evaluation  is  a  LAN 
internetwork.  The  LAN  internetwork  consists  of  two  802.3  LANs  interconnected  through 
a  FDDI  backbone.  The  hosts  and  relays  associated  with  this  network  use 
communications  and  security  protocols  that  have  been  defined  or  adopted  by  the  ISO 
for  use  within  the  framework  of  the  OSI  RM.  Three  different  types  of  relays  are  used  to 
connect  the  802.3  LANs  to  the  FDDI  backbone: 

•  Secure  bridge  [Secure  Data  Exchange  (SDE)  protocol  at  layer  2] 

•  Secure  router  [Network  Layer  Security  Protocol  (NLSP)  at  layer  3] 

•  Secure  transport  relay  [Transport  Layer  Security  Protocol  (TLSP)  at  layer  4]. 

These  relays  provide  the  basis  for  the  three  network  configurations  shown  in 
Figure  1.2-1  (a,  b  and  c).  The  host-to-host  delivery  time  across  each  of  these  network 
configurations  varies,  since  the  processing  delay  through  the  bridges  (1.2-1  a)  is  less 
than  the  delay  through  the  routers  (1.2-1b)  which  is  less  than  the  delay  through  the 
transport  relays  (1.2-1c).  Detailed  rationale  for  the  selection  of  these  network 
configurations  is  provided  in  Sections  2  and  3. 

To  evaluate  the  host-to-host  delivery  time  across  the  three  network 
configurations,  available  literature  was  investigated  to  find  relevant  results  based  on; 

•  Analysis 

•  Testing 

•  Simulation. 

The  scope  of  this  effort  includes  consideration  of  any  combination  of  the  above 
methods  to  evaluate  the  delivery  times  for  each  of  the  three  network  configurations. 
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FODi  =  Fiber  Distributed  Data  Interface 


Figure  1 .2-1 .  Network  Configurations  Used  for  Study 

The  primary  focus  of  Task  1  is  to  determine  quantitatively  the  extent  to  which 
delivery  times  can  be  reduced  by  implementing  security  protocols  at  lower  OSI  layers  in 
relays  (or  front  ends).  This  is  demonstrated  using  a  network  configuration  that 
incorporates  security  protocol  mechanisms  which  protect  the  OSI  communication 
protocols  that  are  in  use. 
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1.3  Study  Objective 

The  objective  of  this  study  is  to  determine  quantitatively  if  the  implementation  of 
security  protocols  at  lower  OSI  layers  in  relays  (or  front  ends)  will  significantly  reduce 
delivery  time  across  a  LAN  internetwork. 

1.4  Approach 

This  study  was  based  upon  a  methodology  which  consists  of  the  following  steps; 

•  Define  network  configuration  for  evaluating  delivery  time 

•  Develop  mathematical  model  for  computing  delivery  time 

•  Search  for  relevant  sources. 

The  relationships  among  these  steps  is  shown  in  Figure  1.4-1.  A  description  of 
each  step  is  provided  below. 


Figure  1.4-1.  Overview  of  Task  1  Study  Approach 
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Stop  1  -  Define  Network  Configuration  for  Evaluating  Delivery  Time 

in  step  1 .  a  network  configuration  was  selected  to  evaluate  how  delivery  time  is 
affected  by  where  security  protocols  are  placed  within  an  OSI  stack.  For  any  given 
network,  the  layers  at  which  security  protocols  are  placed  within  relays  or  front  ends 
may  have  an  impact  on  delivery  time;  their  placement  within  a  host  will  not.  For  this 
reason,  a  network  configuration  was  selected  that  uses  secure  relays,  and  is  of  potential 
and  practical  use  within  shipboard  environments.  This  network  configuration  consists  of 
two  physically  secured  802.3  LANs  interconnected  through  a  backbone  FOOl  LAN.  The 
pair  of  relays  connecting  the  802.3  LANs  to  the  FDDI  backbone  provides  encryption  and 
other  security  services  over  the  FDDI  LAN  through  the  use  of  security  protocols.  This 
basic  network  configuration  had  three  valiants  distinguished  by  the  type  of  secure  relay 
used  —  an  SDE  bridge,  an  NLSP  router,  or  a  TLSP  relay.  Figure  1.2-1  Illustrated  the 
three  variants  of  the  basic  network  configuration  used  to  conduct  this  study. 

Step  2  -  Develop  Mathematical  Model  for  Computing  Delivery  Time 

In  step  2,  mathematical  formulas  were  developed  for  computing  delivery  time  for 
each  of  the  three  network  variants  as  defined  in  step  1 .  At  the  highest  level,  delivery 
time  was  decomposed  into  host  processing  delays  (source  and  destination  hosts),  relay 
processing  delays  (SDE  bridge,  NLSP  router,  and  TLSP  relay),  and  LAN  transmission 
delays  (802.3  and  FDDI).  Host  and  relay  processing  delays  were  further  decomposed 
into  protocol  processing  delays  (application,  presentation,  session.  Transport  Protocol 
Class  4  (TP4),  TLSP,  the  Connectionless  Network  Protocol  (CLNP),  NLSP,  Logical  Link 
Control  (LLC),  SDE,  802.3,  and  FDDI)  and  queuing  delays  between  protocol  entities 
across  adjacent  layers.  LAN  transmission  delays  were  further  decomposed  into  access, 
transmission  and  propa^tion  delays.  This  mathematical  foundation  provided  a  model 
for  computing  delivery  time  and  also  served  to  focus  the  search  for  relevant  technical 
reference  material  sources. 

Step  3  -  Search  for  Relevant  Sources 

In  step  3,  a  variety  of  literature  searches  were  conducted  to  identify  relevant 
sources  for  this  Task  1  effort.  This  included  a  classified  Defense  Technical  Information 
Center  (DTIC)  search,  an  Internet  search,  and  a  search  of  the  University  of  California 
Library  system.  Literature  searches  were  based  on  the  following  major  keywords:  OSI, 
protocol,  network,  LAN,  FDDI,  ethemet,  802.3,  router,  bridge,  host,  COMSEC  (or 
encryption),  board  (or  module),  performance,  delay,  time,  security,  analysis,  simulation, 
and  testing.  Examples  of  keyword  combinations  used  to  search  for  relevant  sources 
included:  OSI  and  testing,  routers  and  delay,  protocols  and  simulation,  and  LANs  and 
testing. 
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1.5  Report  Organization 

The  main  body  of  the  report  is  organized  as  follows: 

•  Section  1  -  Introduction 

•  Section  2  -  Description  of  Basic  Network  Configuration  /  Protocols 

•  Section  3  -  Selection  of  Secure  Network  Configurations 

•  Section  4  -  Mathematical  Model  for  Computing  Delivery  Time 

•  Sections-  Overview  of  Related  Work 

•  Section  6  -  Conclusions  and  Recommendations. 

The  following  appendices  are  provided  to  supplement  the  main  body; 

•  Appendix  A-  Acronyms 

•  Appendix  B-  References. 
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2.0  Description  of  Basic  Network  Configuration  /  Protocois 


Figure  2.0-1  is  representative  of  a  network  which  can  be  used  to  support  Naval 
communications  requirements  aboard  a  ship,  it  consists  of  a  single,  backbone  FDDI 
Local  Area  Network  (LAN)  that  interconnects  multiple  802.3  LANs  through  relays.  The 
802.3  LANs  directly  support  attached  hoste.  This  basic  network  configuration  forms  the 
basis  for  this  study  to  evaluate  the  impact  of  security  protocols  on  delivery  times. 


Figure  2.0-1 .  Basic  Network  Configuration  for  Ships 

This  section  provides  background  for  the  reader  by  describing  the 
communications  and  security  protocols  that  are  used  in  the  basic  network  configuration. 
An  assumption  is  made  that  hosts  and  relays  specified  all  use  protocois  that  have  been 
developed  or  adopted  by  the  ISO  for  use  in  the  OSI  RM.  The  general  OSI 
communications  protocois  that  apply  to  the  basic  network  are  tiius: 

•  IEEE  802.3  Carrier  Sense  Multiple  Access  with  Collision  Detection  (CSMA  /  co) 

•  Rber  Distributed  Data  Interface  (FDDI) 

•  IEEE  802.2  Logical  Link  Control  (LLC) 

•  Connectionless  Network  Protocol  (CLNP) 

•  T ransport  Protocol  Class  4  (TP4). 

Candidate  security  protocols  which  can  be  used  to  secure  this  network  are: 

•  IEEE  802. 1 0(B)  Secure  Data  Exchange  (SDE) 

•  Security  Protocol  3  (SP3) 

•  Network  Layer  Security  Protocol  (NLSP) 

•  Security  Protocol  4  (SP4) 

•  Transport  Layer  Security  Protocol  (TLSP). 
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2.1  General  OSI  Communications  Protocols 

The  following  paragraphs  briefly  describe  the  general  OSI  communications 
protocols  that  apply  to  the  ^ic  network  used  in  this  study. 

2.1 .1  IEEE  802.3  CSMA  /  CD 

The  IEEE  802.3  protocol  operates  at  the  Media  Access  Control  (MAC)  sublayer 
and  is  a  contention-based  protocol.  When  a  frame  is  ready  for  transmission,  the 
chann^  is  first  sensed.  If  the  channel  Is  idle,  the  frame  is  transmitted.  If  it  is  not  idle, 
8ie  station  waits  for  channel  to  become  idle  and  then  transmits  frame.  If  a  collision 
occurs,  ttie  station  waits  a  random  time  period  and  starts  the  process  over. 

The  CSMA/CD  PDU  begins  with  a  preamble  consisting  of  alternating  ones  and 
zeros  for  clock  synchronization,  and  a  one-octet  start  frame  delimiter.  Source  and 
destination  MAC  addresses  may  be  16  or  48  bits  in  length.  All  stations  on  a  given  IEEE 
802.3  LAN  must  however  use  the  same  address  length.  Padding  needed  for  proper 
collision  detection  and  timing  requirement  is  added  in  a  pad  field  to  make  the  frame  a 
minimum  of  64  octets  from  the  destination  address  to  the  Frame  Check  Sequence 
(FCS),  inclusive.  The  PDU  is  completed  witii  a  32-bit  FCS  field. 

2.1 .2  Rber  Distributed  Data  interface  (FDDi) 

The  ANSI  Fiber  Distributed  Data  Interface  (FDDI)  protocol  operates  at  the  MAC 
sublayer  and  is  a  contention-free  protocol.  To  provide  transmission  opportunities  for 
FDDI  stations,  a  token  circulates  on  the  ring.  In  order  to  transmit  a  data  frame,  a  station 
must  first  seize  the  token.  When  a  station  finishes  transmitting  data,  it  must  then 
regenerate  the  token.  Each  station  is  responsible  for  removing  its  data  from  the  ring 
when  it  returns. 

An  FDDi  token  consists  of  the  preamble,  the  ’JK”  starting  delimiter,  a  Frame 
Control  field,  and  the  "T”  ending  delimiter.  AN  FDDI  data  frame  consists  of  a  preamble 
that  is  at  least  16  symbols  of  idle,  the  *JK*  starting  delimiter,  a  Frame  Control  field, 
destination  and  source  MAC  addresses,  data,  a  Frame  Check  Sequence,  the  "T*  ending 
delimiter,  and  tfie  ”RSRS*  frame  status  field.  Repeater  stations  may  shorten  or 
lengthen  the  preamble  as  necessary  for  Physical  Layer  clocking  requirements. 

2.1 .3  IEEE  802.2  Logical  Link  Control  (LLC) 

The  Logical  Link  Control  (LLC)  protocol  transfers  information  and  control 
between  any  pair  of  data  link  layer  Service  Access  Points  (SAPs)  on  a  LAN.  There  are 
two  types  of  LLC  service:  Type  1  which  provides  a  connectionless  mode  without 
acknowledgment  (acknowledgments  by  higher  layers  can  be  used),  flow  control,  or  error 
recovery;  ^  Type  2  which  provides  connection  oriented  service  with  acknowledgment 
(via  ACK  PDU),  flow  control  (via  sequence  numbering  and  Receive  Ready  /  Receive 
Not  Ready),  and  error  recoveiy  (via  Reject  PDU).  The  LLC  Type  1  protocol  is  used  for 
this  study. 
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A  Type  1  LLC  header  consists  of  a  Control  octet.  Source  Service  Access  Point 
(SSAP),  and  Destination  Service  Access  Point  (DSAP).  SSAPs  and  DSAPs  are  known 
collectively  as  Link  Service  Access  Points  (LSAPs).  LSAPs  are  one  octet  in  length  and 
identify  the  users  of  the  LLC  protocol,  usually  protocols  at  a  higher  layer  within  the 
station  (e.g..  an  ISO  network  layer  protocol  or  the  DoD  Internet  Protocol).  For  this 
study,  they  are  used  to  identify  CLNP. 

2.1.4  Connectionless  Network  Protocol  (CLNP) 

The  CLNP  is  used  to  route  packets  across  an  internetwork  and  supports 
connectionless  network  services.  It  allows  packets  to  be  fragmented  (divided  into 
smaller  packets  called  segments)  and  enter  a  subnetwork  which  supports  a  smaller 
maximum  packet  size  than  the  subnetwork  it  is  leaving.  The  segments  for  a  given 
packet  are  ultimately  recombined  at  the  destination.  CLNP  headers  contain  source  and 
destination  addresses.  These  addresses  have  global  significance  within  the  context  of 
the  internetwork  arxi  are  used  to  represent  hosts  and  gateways.  These  addresses  can 
also  be  chosen  indeperxJentiy  from  the  subnet-specific  addresses  that  identify  network 
components.  CLNP  includes  a  16-blt  checksum  that  this  is  computed  over  the  CLNP 
header. 


2.1 .5  Transport  Protocol  Class  4  (TP4) 

The  Connection  Oriented  Transport  Protocol  (COTP)  provides  five  different 
protocol  classes  (Classes  0  through  4).  The  Transport  Protocol  Class  4  (TP4)  is 
generally  used  with  connectionless  network  protocols  (such  as  CLNP)  which  can  lose  or 
reorder  PDUs;  or  deliver  PDUs  with  undetected  errors.  TP4  is  capable  of  using  a  16’bit 
checksum  to  detect  damaged  PDUs  and  7>  or  31 -bit  sequence  numbers  to  detect  lost 
or  duplicate  PDUs.  TP4  provides  multiplexing  (multiple  transport  connections  over  one 
network  connection),  explicit  flow  control,  checksumming,  frozen  references, 
retransmission  on  time-out  to  cope  with  unsignalled  transport  PDU  loss  by  the  network 
sen/ice  provider,  resequencing  to  cope  with  unsignalled  network  connection  termination, 
and  splitting  (one  transport  connection  over  multiple  network  connections).  TP4  also 
uses  a  variety  of  control  and  data  TPDUs.  The  Connection  Request  (CR)  and 
Connection  Confirm  (CC)  TPDUs  contain  identifiers  for  the  calling  and  called  Transport 
Service  Access  Point  ^SAPs). 
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Z2  Security  Protocols 

The  following  paragraphs  briefly  describe  the  security  protocols  which  can  secure 
the  basic  network  configuration  used  in  this  study. 

2.2.1  IEEE  802.1 0  (Clause  2)  Secure  Data  Exchange  (SDE) 

The  Secure  Data  Exchange  (SOE)  Protocol  is  implemented  at  the  Data  Link 
Layer,  as  part  of  the  logical  link  controi  (LLC)  sublayer.  SDE  augments  standard  LLC 
and  MAC  communications  protocols  without  replacing  those  protocols.  An  SDE-specific 
PDU  encapsulates  the  LLC  PDU  and  has  optional  elements  and  fields  to  satisfy  a 
variety  of  potential  security  applications.  SDE  requires  no  change  to  existing  upper- 
layer  protocols  in  the  stack.  SDE  will  operate  in  LANs  where  all  stations  do  not  use 
SDE.  The  SDE  PDU  has  a  clear  header  portion  which  includes  a  unique  Link  Service 
Access  Point  (LSAP)  address  to  distinguish  the  SDE  PDU  from  unprotected  LLC  PDUs. 

SDE  is  a  security  protocol  that  is  designed  to  provide  connectionless 
confidentiality  and  integrity  services  through  encapsulation  of  LLC  PDUs  using 
encryption,  an  integrity  check  value  (ICV),  or  both.  The  data  confidentiality  and  data 
integrity  services  can  be  provided  to  in  both  end  systems  and  intermediate  systems. 
SDE  also  supports  data  origin  authentication  and  access  control.  Data  origin 
authentication  is  achieved  through  the  use  of  the  integrity  service,  or  through  the  use  of 
key  management  and  the  placement  of  a  Station  ID  in  the  SDE  protected  header. 
Access  control  is  provided  by  key  management  or  system  management.  Access  control 
dedstons  are  based  on  the  use  of  security  associations.  Access  controi  is  dependent 
on  both  integrity  and  authentication  services. 

2.2.2  Security  Protocol  (SP3) 

Security  Protocol  3  (SP3)  provides  connectionless  security  services,  and 
assumes  that  it  is  operating  over  a  connectionless  network  service.  It  operates  in  both 
end  systems  and  intermediate  systems,  and  does  not  preclude  the  use  of  unprotected 
communications  between  a  system  which  has  SP3  and  one  that  does  not. 

SP3  provides  connectionless  confidentiality  and  integrity  by  encapsulating 
network  SDUs  using  encryption  and  integrity  check  values.  It  also  provides  access 
control  (based  on  a  label  and  network  service  access  points).  SP3  has  no  security 
association  PDU  and  must  rely  on  external  key  management  protocols  for  security 
association  (SA)  establishment.  The  Key-ID  field  references  the  traffic  encryption  key 
(TEK)  and  associated  security  attributes  that  are  maintained  in  the  security 
management  information  bases  (SMIBs)  of  botii  hosts  for  the  SP3  peer  entities. 
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2J2.3  Network  Layer  Security  Protocol  (NLSP) 

The  Network  Layer  Security  Protocol  (NLSP)  provides  the  security  services  at 
Layer  3  which  are  not  provided  by  standard  communications  protocols.  It  does  not 
replace  standard  communications  protocols,  but  augments  them.  NLSP  can  be 
implemented  in  end  systems  and  intermediate  systems  to  provide  end-to-end 
encapsulation  or  link  encapsulation  of  higher  level  PDUs.  Other  primary  functions 
beyond  encapsulation  include  padding  and  connection  authentication. 

NLSP  provides  the  option  for  performing  an  encipherment  or  integrity  key 
exchange  internally.  This  allows  key  management  to  be  removed  from  the  application 
layer.  It  also  works  if  key  management  is  performed  externally.  Before  secure 
communications  can  be  accomplished,  security  association  attributes  must  be 
negotiated. 

2J2A  Security  Protocol  (SP4) 

Security  Protocol  4  (SP4)  operates  with  both  connection-oriented  and 
connectionless  transport  protocols  and  does  not  preclude  the  use  of  unprotected 
communications.  Therefore,  SP4-capable  hosts  can  operate  in  networks  where  not  all 
stations  use  SP4  and  can  communicate  with  both  protected  and  unprotected  hosts  if 
that  is  allowed  by  the  local  security  policy.  SP4  encap^late  Transport  PDUs  using 
encryption  and  integrity  check  values  to  provide  confidentiality  and  integrity  services.  It 
uses  sequence  numbers  internal  to  the  transport  protocol  to  provide  connection 
integrity.  Transport  PDUs  can  also  be  labeled  and  padded. 

SP4  allows  for  the  use  of  a  Final  Sequence  Number  (FSN)  to  detect  truncation 
(the  deletion  of  the  PDUs  transmitted  at  the  end  of  a  transport  connection).  The  FSN 
field  conveys  the  sequence  numbers  of  the  last  PDUs  sent  and  transmitted  over  the 
transport  connection  so  that  botii  sides  can  determine  if  all  PDUs  have  been  received. 

2^.5  Transport  Layer  Security  Protocol  (TLSP) 

The  Transport  Layer  Security  Protocol  (TLSP)  can  support  connectionless  or 
connection-oriented  confidentiality  and  integrity  senrices.  Implementation  of  TLSP  on  a 
host  does  not  preclude  the  use  of  unprotected  communications  between  transport 
protocol  entities  because  the  formats  of  all  parameters  sent  down  from  the  Transport 
Layer  communications  protocol  are  preserved  and  passed  to  the  Network  Layer. 
Encapsulation  is  performed  by  TLSP  after  all  transport  protocol  processing  is  performed 
and  prior  to  multiplexing  and  assignment  to  the  network  connection.  A  security  label 
can  be  associated  with  each  encapsulated  transport  PDU  and  security  padding  can  be 
used  to  support  cryptographic  algorithm  requirements  for  both  confidentiality  and 
integrity.  Connection  establishment  PDUs  can  be  exchanged  to  perform  peer-entity 
authentication  at  the  transport  layer. 

TLSP  encapsulates  transport  TPDUs  using  encipherment  and  an  integrity  check 
value  to  provide  host-to-host  confidentiality  and  integrity  senrices.  Sequence  numbers 
within  tile  transport  protocol  are  used  to  provide  connection  integrity.  TLSP  does  not 
support  the  FSN  feature  provided  by  SP4. 
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3.0  Selection  of  Secure  Network  Configurations 


The  previous  section  described  the  basic  network  configuration  and  protocols 
used  to  perform  this  task.  This  section  considers  alternative  allocations  of  these 
protocols  to  network  components  and  selects  specific  cases  for  further  investigation. 
Specific  topics  addressed  in  this  section  are: 

•  Allocation  of  security  protocols  arrK)ng  network  components  (hosts  /  relays) 

•  Delay  as  a  function  of  layer  placement  options  /  network  components 

•  Selection  of  preferred  network  configurations  for  study. 

3. 1  Allocation  of  Security  Protocols  Among  Network  Components 


Figure  3.1-1  Illustrates  the  allocation  of  security  protocols  (SPs)  to  hosts  and 
relays  in  a  manner  that  supports  both  physically  secured  802.3  LANs  and  multi-level 
secure  (MLS)  802.3  LANs.  Rationale  for  this  allocation  is  provided  below. 

FPhysicaJly  Secured  LAN  1  f  Physically  Secured  LAnH 


MLS  LAN  (TS/S)  j  I  MLS  LAN  (TS/S)  j 


^  =  Case  1  -  Two  Physically  Secured  LANs 

=  Case  2  -  Physically  Secured  LAN  and  MLS  LAN 

=  Case 3 -Two MLS  LANs 

TS*TOP  SECRET 
SP  =  Security  Protocol 


D 


=Host 

□  s  Relay 

S  = SECRET 

FDDI  =  Fiber  Distributed  Data  Interface 


Figure  3.1-1.  Allocation  of  Security  Protocols  to  Network  Components 
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3.1.1  Physically  Secured  802.3  LANs 

The  physically  secured  802.3  LANs  are  wholly  contained  within  protected  areas 
and,  in  this  figure,  operate  in  a  systems  high  security  processing  mode.  All  of  the  data 
that  is  processed  within  this  LAN  is  therefore  considered  to  be  at  the  same  classification 
level.  (The  assumption  is  made  that  the  hosts  on  this  LAN  cannot  be  trusted  to  protect 
data  at  different  classification  levels.)  Different  physically  secured  LANs  can  however 
operate  at  different  classification  levels.  When  data  is  transferred  from  the  physically 
secured  802.3  LAN  to  the  FDDI  LAN,  it  is  labeled  at  the  classification  level  of  the  LAN, 
protected  against  modification,  and  encrypted  by  a  security  protocol  contained  within  the 
relay.  (If  the  hosts  could  be  trusted  to  process  a  range  of  classification  levels  (MLS 
hosts),  then  the  802.3  LAN  could  operate  in  an  MLS  security  processing  mode  and  the 
secure  relay  could  accept  a  range  of  classification  levels  from  the  802.3  LAN.) 

3.1.2  MLS  802.3  LANs 

With  the  MLS  802.3  LANs,  individual  hosts  operate  in  a  systems  high  processing 
mode,  but  at  different  classification  levels.  (Again  this  discussion  assumes  that  the 
hosts  cannot  be  trusted  to  protect  different  classification  levels  of  data.)  Each  host  has 
a  security  protocol  that  labels  data  at  the  classification  level  of  the  host,  protects  it 
against  modification,  and  enciypts  it  for  transmission  over  the  802.3  LAN.  The  security 
protocol  also  checks  the  classification  level  of  incoming  data  to  see  if  it  can  be  accepted 
by  the  host.  In  this  way,  the  systems  high  hosts  collectively  form  an  MLS  802.3  LAN 
using  the  security  protocols  associated  with  each  host.  (If  the  hosts  could  be  trusted  to 
process  a  range  of  classification  levels  (MLS  hosts),  then  the  security  protocol  could 
accept  a  range  of  classification  levels  from  the  host).  In  this  situation,  data  can  be 
transferred  transparently  through  the  relay  from  the  MLS  802.3  LAN  to  the  FDDI  LAN. 

3.1 .3  Exchanges  Among  802.3  LANs 

In  addition  to  illustrating  the  allocation  of  security  protocols,  Figure  3.1-1  identifies 
three  cases  for  how  data  can  flow  over  ttie  FDDI  backbone  between  the  802.3  LANs: 

•  Between  physically  secured  LANs  -  corresponding  security  protocols  lie  in 
relays 

•  Between  a  physically  secured  LAN  and  an  MLS  LAN  -  corresponding  security 
protocols  lie  in  relay  and  host 

•  Between  MLS  LANs  -  corresponding  security  protocols  lie  In  hosts. 

The  existence  of  these  three  cases  raises  a  question  —  which  case  would  be 
most  appropriate  for  conducting  this  study.  To  answer  this  question  requires  that  the 
impact  on  delivery  time  for  different  placement  options  in  hosts,  front  ends  and  relays  be 
analyzed.  This  is  done  qualitatively  in  the  following  section. 
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3^  Delay  as  a  Function  of  Placement  Options  /  Network 
Components 

This  section  analyzes  in  qualitative  terms  the  impact  on  delivery  time  of  different 
placement  options  for  security  protocols  within  the  following  types  of  network 
components: 

•  Hosts 

•  Front  ends 

•  Relays. 

3.2.1  Delay  as  a  Function  of  Placement  Options  for  Hosts 

Figure  3.2.1 -1  (a, b  and  c)  illustrates  host  stacks  that  each  use  a  different  type  of 
security  protocol  at  different  layers.  SDE  is  used  at  layer  2  in  Figure  3.2. 1-1  a;  NLSP  is 
used  at  layer  3  in  Figure  3.1 .1-1b;  while  TLSP  is  used  at  layer  4  in  Figure  3.2.1-1c.  The 
host  processing  delay  is  relatively  insensitive  to  the  layer  at  which  a  security  protocol  is 
placed  because: 

•  Each  host  processes  data  only  once  at  each  of  the  seven  OSI  layers  using 
the  same  OSI  communications  protocol 

•  Each  host  incorporates  a  single  security  protocol.  Although  these  security 
protocols  (SDE,  NLSP,  and  TLSP)  are  of  different  types,  each  performs 
similar  functions,  such  as:  generating  protected  headers,  clear  headers, 
padding  and  integrity  check  values  (ICVs),  as  well  as,  encryption  of  data. 

The  following  factors  will  however  give  rise  to  minor  differences  in  the  host 
processing  delays: 

•  Small  differences  in  processing  delays  are  inevitable  because  of  the 
differences  in  the  amount  of  processing  required  for  different  security 
protocols. 

•  Processing  of  ICVs  and  encryption  at  lower  layers  take  longer  because  the 
service  data  units  (SDUs)  are  larger  and  have  more  headers. 

In  conclusion,  the  processing  delay  in  a  host  is  relatively  insensitive  to  the  layer 
at  which  its  security  protocol  is  implemented. 
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3^.2  Delay  as  a  Function  of  Placement  Options  for  Host  Front 
Ends 

Figure  3.2.2- 1  illustrates  three  identical  hosts  that  each  use  different  secure  front 
ends.  These  secure  front  ends  allow  the  hosts  to  be  connected  to  a  secure  network 
without  modifying  the  host  (transparent  connection  to  network).  Each  of  these  secure 
front  ends  uses  a  different  type  of  security  protocol  at  a  different  layer.  In 
Figure  3.2.2-1a,  the  front  end  uses  SDE  at  layer  2,  while  in  Figure  3.2.2-1b,  NLSP  is 
used  at  layer  3.  TLSP  is  used  at  layer  4  with  the  front  end  shown  in  Figure  3.2.2-1c. 


Host 


Host 


Host 


Figure  3.2.2-1 .  Comparison  of  Delay  through  Secure  Front  Ends 
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The  processing  delay  associated  with  a  secure  front  end  is  sensitive  to  the  layer 
at  which  its  security  protocol  is  located.  When  its  security  protocol  is  placed  at  a  higher 
layer,  the  processing  delay  is  greater.  This  results  from  the  processing  of  additional  OSI 
communications  protocols  within  front  ends  tfiat  use  security  protocols  at  higher  layers. 
This  additional  delay  occurs  on  both  sides  of  the  secure  front  end.  This  effect  can  be 
observed  in  Figure  3.2.2- 1b.  In  this  case,  the  secure  NLSP  front  end  must  process 
CLNP  headers  on  the  host  and  network  sides  that  are  not  processed  by  the  secure  SDE 
front  end  in  Figure  3.2.2-1a.  In  Figure  3.2.2-lc,  the  secure  TLSP  front  end  must  also 
process  TP4  headers  on  the  host  and  network  sides  in  a  manner  similar  to  the  secure 
NLSP  front  end.  The  result  is  that  greater  processing  delays  occur  in  front  ends  that 
use  security  protocols  at  higher  layers. 

3.2.3  Delay  as  a  Function  of  Placement  Options  for  Relays 

Figure  3.2.3-1  illustrates  three  relays  that  each  use  a  different  type  of  security 
protocol  at  a  different  layer.  In  Figure  3.2.3-1a.  the  relay  uses  SDE  at  layer  2.  In 
Figure  3.2.3-1b,  NLSP  is  used  at  layer  3.  TLSP  is  used  at  layer  4  in  the  relay  shown  in 
Figure  3.2.3-lc. 
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Figure  3.2.3~1 .  Comparison  of  Delay  through  Secure  Relays 
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The  processing  delay  associated  with  a  secure  relay  is  sensitive  to  the  OSI  layer 
at  which  its  security  protocol  is  located.  When  its  security  protocol  is  placed  at  a  higher 
layer,  its  processing  delay  is  increased.  This  results  from  the  processing  of  additional 
OSI  communications  protocols  within  relays  that  use  security  protocols  at  higher  layers. 
This  additional  delay  occurs  on  both  sides  of  the  secure  relay.  This  effect  can  be 
obsenred  in  Figure  3.2.3-1b.  In  this  case,  the  secure  NLSP  relay  must  process  CLNP 
headers  on  both  sides  because  these  are  not  processed  by  the  secure  SDE  relay  as  in 
Rgure  3.2.3- la.  In  Figure  3.2.3- 1c,  the  secure  TLSP  relay  must  also  process  TP4 
headers  on  both  sides  in  a  manner  similar  to  the  secure  NLSP  relay.  The  result  is  that 
greater  processing  delays  occur  in  relays  that  use  security  protocols  at  higher  layers. 

3^.4  Summary  Observations  Regarding  Deiay 

Based  upon  the  analysis  presented  in  Section  3.2,  the  following  observations 
regarding  the  impact  on  delivery  time,  as  a  result  of  placing  security  protocols  at 
different  layers  within  hosts,  front  ends,  and  relays,  can  be  summarized  as  follows; 

•  Host  processing  delay  is  relatively  insensitive  to  the  choice  of  which  layer  the 
security  protocols  is  placed. 

•  Processing  delay  within  a  front  end  or  relay  is  increased  when  security 
protocols  are  placed  at  higher  layeis. 
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3.3  Selection  of  Preferred  Network  Configurations  for  Study 

A  network  configuration  that  incorporates  security  protocols  in  relays  has  been 
ictentifiecl  for  this  study  since: 

•  It  has  two  network  components  (the  two  relays)  that  are  each  sensitive  to  the 
layer  at  which  security  is  placed  [host-to-relay  and  hosHo-host  configurations 
include  one  component  and  no  components,  respectively,  that  are  sensitive  to 
where  security  is  placed  (assuming  the  hosts  do  not  use  front  ends). 

•  it  addresses  a  configuration  that  is  potentially  useful  to  the  Navy  in  the  near 
term.  Using  secure  relays  to  interconnect  physically  secured  LANs  at  the  Top 
Secret  /  Sensitive  Compartmented  Information  TS  /  SCI  and  SECRET  level 
over  an  FDD!  backbone  is  potentially  more  cost-effective  than  incorporating 
security  protocols  in  every  workstation. 

This  network  configuration  is  further  divided  into  three  cases  in  which  the  secure 
relay  is  either  a  bridge,  router  or  transport  relay.  The  specific  allocation  of 
communications  and  security  protocols  to  the  various  network  components  for  each  of 
these  cases  is  shown  in  Figures  3.3-1  a,  3.3-1  b,  and  3.3-1  c. 


Bridge  Bridge 

Figure  3.3-1  a.  Network  Configuration  with  Secure  Bridges 
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Figure  3.3-1  b.  Network  Configurador)  with  Secure  Routers 


Figure  3.3-1  c.  Network  Configuration  with  Secure  Transport  Reiays 
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4.0  Mathematical  Model  for  Computing  Delivery  Time 

The  delivery  time  for  traversing  the  internetwork  shown  in  Figure  4,0-1  is  given 
by: 

1'clellvery-time  ~  T^host(down)  +  T 802.3 

+  Tr0iay(8O2.3-to-FDDI,SP)  +  TpDDI 

+  Tr0iay(FDDI-to-8O2.3,SP)  +  T802.3 
+  Thost(up) 


_ A _ 

Treiay  (802.3-to-FDDI,  SP) 


Figure  4.0-1.  Mathematical  Model  for  Computing  Delivery  Time 

where 

TfBiay(802.3-to-FDDI,SP)  =  Average  time  that  relay  takes  to  internally  process  data  from  time  it 

is  received  on  802.3  LAN  to  time  it  is  ready  for  transmission  on 
FDDILAN 

Treiay(FDOI-to-802.3,SP) »  Average  time  toat  relay  tates  to  internally  process  data  from  time  it 

is  received  on  FDDI  LAN  to  time  it  is  ready  for  transmission  on 
802.3  LAN 

Thost(do^)  =  Average  interval  from  time  that  data  is  first  passed  down  to  the  application 
layer  from  the  application  process  to  time  that  a  frame  is  ready  for 
transmission  over  the  802.3  LAN 

Average  time  to  exchange  frame  between  host  and  relay  over  802.3  LAN 
Average  time  needed  to  transfer  frame  between  relays  over  FDDI  LAN 
Average  interval  from  time  that  data  is  first  received  at  host  from  802.3  LAN 
to  time  that  data  is  ready  for  application  process  at  destination 
Parameter  representing  security  protocol  within  relay  that  can  take  on  the 
values  —  SDE,  NLSP  or  TLSP 
Parameter  indicating  that  data  is  moving  up  stack 
Parameter  indicating  that  data  is  moving  down  stack. 


T802.3  = 

tfddi  = 

Th08t(up)  = 

SP  = 

up  = 
downs 
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The  fbliowing  subsections  provide  specific  formulas  for  T host(down),  T host(up), 
Trelay (802.3, FDDI, SP),  Trelay(PDDI, 802.3, SP),  7002.3  and  TfdDI.  The  notation  that 
follows  is  used  throughout  these  subsections: 

TcJown(x)  -  Average  time  taken  by  protocol  x  to  generate  its  headers  /  trailers 
and  prepend  /  postpend  them  to  the  service  data  unit  (SDU)  from 
the  layer  above.  Security  protocols  can  also  insert  padding, 
compute  an  integrity  check  value  (ICV),  and  perform  encryption. 

Tdown(x,y)  ==  Average  waiting  time  in  queue  for  SDUs  that  are  transferred 
across  a  layer  boundary  from  protocol  x  (layer  above)  to  protocol 
y  (layer  below);  or  from  a  relay  /  routing  function  to  the  uppermost 
protocol.  For  some  layer  boundaries  and  implementations  this 
delay  may  not  exist  (equals  zero),  since  adjacent  protocols 
process  data  immediately  without  the  data  having  entered  a 
queue. 

Tup(x)  =  Average  time  taken  by  protocol  x  to  process  its  received  headers 
/  trailers  and  remove  them.  Security  protocols  can  also  remove 
padding,  re-compute  ICVs,  and  perform  decryption. 

Tup(x,y)  =  Average  waiting  time  in  queue  for  SDUs  that  are  transferred 
across  layer  boundary  from  protocol  x  (layer  below)  to  protocol  y 
(layer  above);  or  from  the  uppermost  protocol  to  the  relay  / 
routing  function.  For  some  layer  boundaries  and 
implementations  this  delay  may  not  exist  (equals  zero),  since 
adjacent  protocols  process  data  immediately  without  the  data 
having  entered  a  queue. 

x,y  =  Parameters  used  to  represent  protocol  entities  or  a  relay  /  routing 

function;  parameters  can  take  on  values:  802.3,  SOE,  LLC, 
CLNP,  NLSP,  TLSP,  TP4,  sess,  pres,  appi,  or  relay. 
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4. 1  Host  Processing  Delays 

The  host  processing  delay  represents  the  time  that  a  host  takes  to  internally 
process  data.  There  are  two  host  processing  delays  —  one  at  the  source  host  and  one 
at  the  destination  host. 

4.1 .1  Source  Host  Processing  Delay,  Thost(clown) 

The  source  host  processing  delay,  Thost(<^own),  is  given  by; 

Thost(down)  =  T  down(appl)  +  T  down  (appi, pres) 

+  T down  (pres)  +  TdownCpres.sess) 

+  T  down  (sess)  +  T  down  (s6ss,TP4) 

+  T  down  (TP4)  +  T  down  (TP4,CLNP) 

+  Tdown(CLNP)  +  Tdown(CLNP.LLC) 

+  T  down{LLC)  +  T  down  (LLC, 802.3)  +  Tdown  (802.3). 

4.1 .2  Destination  Host  Processing  Delay,  Thost(up) 

The  destination  host  processing  delay,  Thost(up)>  9' van  by; 

Thost(up)  *  Tup(802.3)  +  Tup(802.3,LLC) 

+  Tup(LLC)  +  Tup(LLC,CLNP) 

+  Tup(CLNP)  +  Tup(CLNP,TP4) 

+  T  up(TP4)  +  T  up(TP4,sess) 

+  T  up(sess)  +  T  up(sess,pres) 

+  T  up(pres)  +  Tup(pres,app)  +  T  up(app). 
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4J?  Processing  Delay  through  Relays 

The  processing  delay  through  a  relay  represents  the  time  interval  that  a  relay 
takes  to  internally  process  data  from  the  time  it  is  received  to  the  time  it  is  ready  for 
transmission.  This  processing  delay  is  ansdyzed  for  the  following  three  cases; 

•  A  secure  SDE  bridge 

•  A  secure  NLSP  router 

•  A  secure  TLSP  relay, 

4.2.1  Processing  Delay  through  a  Secure  Bridge 

The  network  under  investigation  uses  two  secure  relays.  For  a  given  direction  of 
transmission,  one  relay  receives  frames  from  an  802.3  LAN  and  fonvards  them  over  an 
FDDI  LAN;  the  other  receives  frames  on  the  FDDI  LAN  and  forwards  them  over  the 
802.3  LAN.  Each  of  these  cases  is  covered  below  . 

4.2.1 .1  From  802.3  to  FDDI  over  Secure  Bridge 

The  processing  delay  through  a  secure  SDE  bridge  that  receives  frames  from  an 
802.3  LAN  and  forwards  them  over  an  FDDI  LAN  is  given  by: 

Trelay(802.3-to-FDDI,  SDE)  =  Tup(802.3)  +  Tup(802.3,LLC) 

+  Tup(LLC)  +  Tup{LLC.relay) 

+  T  relay  +  Tdown  (relay  ,LLC) 

+  T  down{LLC)  +  T  down  (LLC, SDE) 

+  Tdown(SDE)  +  Tdown  (SDE, FDDI) 

+  Tdown(FDDI). 

4.2.1 .2  From  FDDI  to  802.3  over  Secure  Bridge 

The  processing  delay  through  a  secure  SDE  bridge  that  receives  frames  from  an 
FDDI  LAN  and  forwards  them  over  an  802.3  LAN  is  given  by: 

Trelay(FDDI-to-802.3.  SDE)  =  Tup(FDDI)  +  Tup(FDDI,SDE) 

+  Tup(SDE)  +  Tup(SDE,LLC) 

+  T  up(LLC)  +  T  up(LLC, relay) 

+  T  relay  +  Tdown  (relay, LLC) 

+  T down  (LLC)  +  T down  (LLC, 802.3) 

+  Tdown  (802,3). 


Secure  Solutions,  Inc. 


4-4 


Contract  No.  N00039-93-C-0099 


Demonstration  of  Concept  (DRAFT) 


August  3, 1994 


4.2.2  Processing  Delay  through  Secure  Router 

The  processing  delay  through  a  secure  NLSP  router  is  covered  for  two  cases: 
frames  flowing  from  802.3  to  FDDI,  and  from  FDDI  to  802.3. 

4.2.2.1  From  802.3  to  FDDI  over  Secure  Router 

The  processing  delay  through  a  secure  NLSP  router  that  receives  frames  from  an 

802.3  LAN  and  forwards  them  over  an  FDDI  LAN  is  given  by: 

Trelay(802.3-to-FDDI.  NLSP)  =  Tup(802.3)  +  Tup(802.3,LLC) 

+  Tup(LLC)  +  Tup{LLC,CLNP) 

+  Tup(CLNP)  +  Tup(CLNP.relay) 

+  T  relay  +  Tdown  (relay, CLNP) 

+  Tdown(CLNP)  +  Tdown  (CLNP.NLSP) 

+  Tdown(NLSP)  +  Tdown  (NLSP.  LLC) 

+  T down  (LLC)  +  T down  (LLC, FDDI) 

+  Tdown  (FDDI). 

4.2.2.2  From  FDDI  to  802.3  over  Secure  Router 

The  processing  delay  through  a  secure  NLSP  router  that  receives  frames  from  an 
FDDI  LAN  and  forwards  them  over  an  802.3  LAN  is  given  by: 

Treiay(FDDI-to-802.3,  NLSP)  =  Tup(FDDI)  +  Tup(FDDI,LLC) 

+  Tup(LLC)  +  Tup(LLC,NLSP) 

+  Tup(NLSP)  +  Tup(NLSP,CLNP) 

+  Tup(CLNP)  +  Tup(CLNP, relay) 

+  Trelay  +  Tdown  (relay, CLNP) 

+  T down  (CLNP)  +  T down  (CLNP.LLC) 

+  T down  (LLC)  +  T down  (LLC, 802.3) 

+  Tdown  (802.3). 
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4.2.3  Processing  Defay  through  Secure  Transport  Relay 

The  processing  delay  through  a  secure  TLSP  relay  is  covered  for  two  cases: 
frames  flowing  from  802.3  to  FDDI,  and  from  FDDI  to  802.3. 

4.2.3.1  From  802.3  to  FDDI  over  Secure  Transport  Relay 

The  processing  delay  through  a  secure  TLSP  relay  that  receives  frames  from  an 

802.3  LAN  and  fonwards  them  over  an  FDDI  LAN  is  given  by: 

Trelay(802.3-to-FDDI.  TLSP)  =  Tup(802.3)  +  Tup(802.3,LLC) 

+  Tup(LLC)  +  Tup(LLC.CLNP) 

+  Tup(CLNP)  +  Tup(CLNP.TP4) 

+  T  up(TP4)  +  T  up(TP4, relay) 

+  T  relay  +  Tdown  (relay  .TP4) 

+  T  down  (TP4)  +  T  down  (TP4, TLSP) 

+  Tdown(TLSP)  +  Tdown(TLSP,CLNP) 

+  Tdown(CLNP)  +  Tdown(CLNP,LLC) 

+  T  down(LLC)  +  T  down  (LLC,  FDDI) 

+  Tdown(FDDI). 

4.2.3.2  From  FDDI  to  802.3  over  Secure  Transport  Relay 

The  processing  delay  through  a  secure  TLSP  relay  that  receives  frames  from  an 
FDDI  LAN  and  forwards  them  over  an  802.3  LAN  is  given  by: 

Treiay(FDDI-to-802.3,  TLSP)  =  Tup(FDDI)  +  Tup{FDDI.LLC) 

+  Tup(LLC)  +  Tup(LLC,CLNP) 

+  Tup(CLNP)  +  TupCCLNP.TLSP) 

+  Tup(TLSP)  +  Tup(TLSP,TP4) 

+  T  up(TP4)  +  T  up(TP4,  relay) 

+  T  relay  +  Tdown  (relay  ,TP4) 

+  T  down(TP4)  +  T  down(TP4,CLNP) 

+Tdown  (CLNP)+Tdown  (CLNP.LLC) 

+  T down  (LLC)  +  T down  (LLC, 802.3) 

+  Tdown  (802.3). 
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4.3  Delays  Across  LANs 

The  average  delay  across  a  LAN  represents  the  interval  from  the  time  a  frame  is 
ready  for  transmission  at  the  source  to  the  time  it  is  received  at  the  destination.  There 
are  two  such  delays  —  one  across  802.3  LANs  and  one  across  FDDI  LANs. 

4.3.1  Delay  Across  802.3  LAN,  T 802.3 

The  average  time  needed  to  exchange  a  frame  between  host  and  relay  over  an 

802.3  LAN  Is  given  by; 

T802.3  =  T802.3(access)  +  T802.3(trans)  +  T802.3(prop) 

where 

T802.3(access)  =  Average  time  needed  to  successfully  gain  access  to  an  802.3 
LAN.  To  transfer  a  frame  over  an  802.3  LAN,  a  STATION  must 
wait  until  the  LAN  becomes  idle.  When  it  does  attempt  to 
transmission,  another  STATION  may  do  the  same.  If  two 
stations  transmit  at  the  same  time,  a  collision  occurs.  Each 
station  must  then  wait  a  random  time  intenral  before  attempting 
a  retransmission.  To  successfully  gain  access  to  an  802.3 
LAN,  a  station  must  therefore  transmit  its  frame  before  other 
stations  do  so.  If  it  transmits  the  frame  for  a  sufficiently  long 
time,  the  other  stations  on  the  LAN  will  detect  that  the  LAN  is 
being  used  and  will  not  attempt  a  transmission.  When  this 
occurs  a  station  has  successfully  gained  access  to  the  LAN. 

T802.3(f'’ans)  =  Time  taken  to  transmit  frame  over  802.3  LAN 

=  Length  of  frame  in  bits  /  transmission  rate  in  bits  per  second 
=  Length  of  frame  in  bits  / 10  Mbps 

T802.3(prop)  =  Time  taken  for  the  first  bit  emitted  by  transmitter  to  arrive  at  the 
receiver  over  the  802.3  LAN 

=  Propagation  delay  across  802.3  LAN  transmission  media. 
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4.3.2  Delay  Across  FDD!  LAN 

The  average  time  needed  to  exchange  a  frame  between  relays  over  an  FDDI 
LAN  is  given  by: 

T fddi  =  T FDDI  (access)  +  T fdDI  (trans)  +  T  fdDI  (prop) 

where 

TfdDI  (access)  =  Average  time  needed  to  successfully  gain  access  to  an  FDDI 
LAN.  (To  transfer  a  frame  on  an  FDDI  LAN,  a  station  must 
first  wait  until  a  token  can  be  seized  at  its  interface  unit). 

T FDDI  (trans)  =  Time  taken  to  transmit  frame  over  FDDI  LAN 

=  Length  of  frame  in  bits  /  transmission  rate  in  bits  per  second 
=  Length  of  frame  in  bits  / 1 00  Mbps 

TFDDl(prop)  =  Time  taken  for  first  bit  emitted  by  transmitter  to  arrive  at  the 
receiver  over  FDDI  LAN 

=  Propagation  delay  across  FDDI  LAN  (includes  propagation 
delay  across  fiber  optic  simplex  links  as  well  as  the  delays 
introduced  within  the  interface  units. 
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5.0  Overview  of  Related  Work 

This  section  describes  the  research  and  methods  undertaken  to  complete  Task  1 
of  this  SBIR  effort.  This  research  was  based  upon  using  a  search  strategy  that  to 
examine  basic  keywords,  such  as:  OSI,  protocol,  network,  LAN,  router,  and  bridge.  The 
results  of  these  queries  were  refined  using  additional  keywords  such  as  performance, 
delay,  time,  security,  analysis,  simulation,  and  testing.  Finally,  a  combinations  of  the 
keywords  were  used  to  further  refine  the  results.  The  following  reference  sources  were 
searched: 

•  Book  search 

•  Periodical  /  proceedings  /  papers  search 

•  Defense  Technical  Information  Center  (OTIC)  search 

•  Internet  search 

•  Vendor  research. 

5.1  Book  Search 

The  book  search  was  performed  at  tfie  University  of  California  San  Diego  library 
(UCSD),  Monmonth  College  library,  various  on-line  libraries  available  on  the  Internet, 
the  San  Diego  Technical  Bookstore,  and  Secure  Solutions'  technical  reference  library 
using  the  keyword  search  methodology.  Bibliographies  were  also  checked  for  additional 
resources.  The  following  books  were  identified  for  potential  use  in  conducting  this  task: 

•  Albert,  Bernard,  FDDI  and  FDDI-II:  Architecture,  Protocols,  and  Performance. 

•  Baker,  Donald  G.,  Local  Area  Networks  with  Fiber  Optic  Applications, 
Prentice-Hail,  Englewood  Cliffs,  NJ,  1986.  Addresses  performance  and 
theoretical  aspects  of  fiber  optic  LANs. 

•  Bertsekas,  Dimitri,  and  Gallager,  Robert,  Data  Networks,  Prentice-Hall, 
Englewood  Cliffs.  NJ,  1992. 

•  Black,  Uyless,  Data  Networks  -  Concepts,  Theory  and  Practice,  Prentice-Hall, 
Englewood  Cliffs,  NJ,  1992. 

•  Conway,  Adrian  E.,  and  Georgonas,  Nicoles  D.,  Queuing  Networks  -  Exact 
Computational  Algorithms:  A  Unified  Theory  Based  on  Decomposition  and 
Aggregation,  MIT  Press,  Cambridge  MA,  1989.  This  book  includes  a  queuing 
model  for  OSI  communications  architectures  in  Section  2.3.9. 

•  Daigle,  John,  Queuing  Theory  for  T eiecommunications,  Addison-Wesley 
Publishing  Company,  Reading  MA,  1991. 

•  Driver  Performance:  Measurement  And  Modeling,  IVHS,  Information 
Systems,  and  Simulation.  Washington.  D.C.:  National  Academy  Press,  1993. 

•  Fortier,  Paul  J.,  Design  &  Analysis  of  Distributed  Real-time  Systems,  Intertext 
Publications,  McGraw-Hill,  New  York,  NY,  1985. 
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•  Fortier,  Paul  J.,  editor,  Modeling  and  Analysis  of  Local  Area  Networks,  CRC 
Press,  1990. 

•  Fortier,  Paul  J.,  Modeling  and  Analysis  of  Local  Area  Networks,  Springer- 
Verlag,  1989. 

•  Hammond,  Joseph  L.,  and  O'Reiley,  Peter  J.,  Performance  Anal^is  of  Local 
Computer  Networks,  Addison-Wesley,  1986. 

•  Hayes,  Jeremiah,  F.,  Modeling  and  Analysis  of  Computer  Communications 
Networks,  Plenum  Press,  New  Yoric,  1984. 

•  Jeruchim,  Michel  C.,  Simulation  of  Communications  Systems,  Plenum,  New 
York,  1992. 

•  Kanuii,  Nanda  K.,  CSMA/CO  LAN  Performance:  Modeling  and  Simulation  in 
CSIM.  1989. 

•  Kelser,  Gerd  E.,  Local  Area  Networks,  McGraw-Hill,  New  York,  NY,  1989. 

•  Kleinrock,  Leonard.  Communication  Nets;  Stochastic  Message  Flow  and 
Delay.  New  York,  McGraw-Hill,  1964. 

•  Kummerle,  Karl;  Limb,  John  O.;  and  Tobagi,  Fouad  A.,  Advances  in  Local 
Area  Networks,  IEEE  Press.  New  York.  1987.  This  book  includes  a  major 
section  on  LAN  performance. 

•  Kumool,  Ramesh,  1965.  Token  bus  LAN  Performance:  Modeling  arKi 
Simulation,  1990. 

•  Network  Modeling,  Simulation,  and  Analysis.  Electrical  Engineering  and 
Electronics;  61.  New  York:  M.  Dekker,  cl  990. 

•  Pasupuleti,  Pratap  S.,  Dual  token  ring  LAN  Performance,  IEEE,  1991 . 

•  Perlman,  Radia,  Interconnections:  Bridges  and  Routers,  Addison-Wesley, 
Redwood  City,  CA,  1992.  Addresses  design,  performance  and  theory  of 
bridges  and  routers. 

•  Pickholtz,  Raymond  I.,  Local  ^ea  and  Multiple  Access  Networks,  Computer 
Science  Press,  Rockville  MD,  1986.  Addresses  design,  performance  and 
measurement  of  LANs. 

•  Robertazzi,  Thomas  G.,  Computer  Networks  and  Systems:  Queuing  Theory 
aruJ  Performance  Evaluation,  Springer-Vertag,  New  York,  1990. 

•  Schwartz,  Mischa,  Telecommunication  Networks:  Protocols,  Modeling,  and 
Analysis,  Addison-Wesley  Publishing  Company,  Menlo  Park,  CA,  1987. 

•  Stallings,  William,  Computer  Communications:  Architecture's,  Protocols,  and 
Standards,  IEEE  Computer  Society  Press.  Los  Alamos  CA,  1992. 

•  Stallings,  William,  editor.  Tutorial  Local  Network  Technology,  IEEE  Computer 
Society  Press,  Silver  Spring,  MA,  1983.  This  book  includes  a  paper  entitled 
"A  methodology  for  Predicting  End-to-End  Responsiveness  in  a  Local 
Computer  Network.* 
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•  Stallings,  William,  Local  Networks  an  Introduction,  Macmillan  Publishing 
Company,  1984.  This  book  includes  a  good  general  reference  on  LAN 
performance. 

•  Stuck,  B,  and  Arthurs,  E.,  A  Computer  and  Communications  Network 
Performance  Analysis  Primer,  Prentice-Hall  software  series,  1985. 

Addresses  performance  and  measurement  of  networks. 

5^  Periodicals  /  Proceedings  /  Papers  Search 

The  periodicals  /  proceedings  /  papers  search  was  performed  at  the  UCSD 
library.  Monmonth  College  library,  various  on-line  libraries  available  on  the  Internet,  and 
Secure  Solutions'  internal  resources  using  the  keyword  search  methodology. 
Bibliographies  were  also  checked  for  additional  resources.  The  following  periodicals  / 
r  ^edings  /  papers  were  identified  for  potential  use  in  conducting  this  task: 

•  Bradner,  Scott,  Ethernet  Bridges  and  Routers:  Faster  than  Fast  Enough, 

Data  Communications,  February  1992  v21  n3  p58(10). 

•  Brown,  Carolyn,  AT&T  System  Solution  Links  Ethernet  and  FDDI,  Multiport 
Bridge  RIters  at  500,000  packets  per  second.  Data  Communication,  August 
1990  v19  mo  pi 28(3). 

•  Bux,  W.,  Meister,  B.,  and  Wong,  J.  W.,  Bridges  for  Interconnection  of  Ring 
Networte  -  a  Simulation  Study,  information  Processing  '83.  Proceedings  of 
the  IFIP  9th  World  Computer  Congress,  Paris,  France,  September  19-23, 

1983  (Vol.  3);  IFIP  World  Congress  Series,  Vol.  9;  North  Holland,  New  York, 
1983. 

•  Denning,  Peter,  Communications  of  the  ACM,  October  1990,  v33,  nIO.  Entire 
issue  is  devoted  to  simulation  and  modeling. 

•  Estrin,  Deborah,  and  Mitzel,  Danny  J.,  An  assessment  of  state  and  lookup 
overhead  in  routers.  Proceedings  Title:  One  World  through  Communications 
(Vol.  3),  IEEE  Computer  Society,  4-8  May  1992,  Florence,  Italy. 

•  Flanagan,  Patrick,  Multiprotocol  Routers:  an  Ovenriew,  Telecommunications, 
April  1993  v27  n4  pi  9(4).  This  product  may  be  pertinent  to  study. 

•  Greenfield,  David,  and  Bradner,  Scott,  Building  the  Highway,  PC  Magazine, 
March  30  1993  v15  n6  p22(33). 

•  Greenfield,  David,  Speedy  Routers  for  FDDI:  Routers  Get  a  Performance  and 
Price  Boost,  Data  Communications,  June  1990  v19  n7  p58(3).  Paper 
indicates  that  improved  speed  of  the  ’newer"  routers  results  from  the 
establishment  of  shared  memory  space  and  the  passing  of  small  memory 
pointers  to  blocks  of  data  ratiier  that  the  data  itself,  the  use  of  high-speed 
(300-Mbps-pius)  buses,  and  fast  32-bit  processors.  This  illustrates  how 
internal  processing  delays  are  affected  by  the  architecture  of  a  relay. 

•  Kritzinger,  P.  S.,  *A  Performance  Model  of  the  OSI  Communications 
Architecture,"  IEEE  Transactions  on  Communications,  June  1986  v34  n6 
p554(9).  Bibliography  identifies  other  pertinent  references. 
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•  Livingston,  Dennis.  "Avoid  being  fooled  by  bridge  and  router  speed  claims", 
Systems  integration,  May  1991,  v24.  nS,  p53(10).  This  article  identifies 
several  independent  test  organizations  and  includes  phone  numbers  for 
vendors  and  Scott  Biadner. 

•  Loudermiik,  Stephen.  Xypiex  Unwraps  Ethemet-to-FDDI  Bridge  /  Router  Pair, 
PC  Week,  August  23 1 993  v1 0  n33  p54(1 ).  This  product  may  be  pertinent  to 
stLKjy. 

•  McCarthy,  Vance,  Xypiex  bridges  FDDI-to-Ethemet  gap  on  desktop:  also 
debuts  low-cost  hub  for  connecting  work  groups  to  a  larger  LAN,  InfoWorld, 
March  15  1 993  v1 5  n1 1  p41  (1 ).  This  product  may  be  pertinent  to  study. 

•  Metcalf,  R.  M..  Boggs,  D.  R..  "Ethernet:  Distributed  Packet  Switching  for 
Local  Computer  Networks,"  Communications  of  the  ACM,  July  1976.  This  is  a 
classic  paper  on  Ethernet  performance. 

•  Mussich,  Paula,  Cisco  Switching  Hubs  Pave  Way  for  Migration  to  ATM,  PC 
Week,  March  7  1994  v1 1  n9  p33(2).  This  product  may  be  pertinent  to  study. 

•  Mussich,  Paula,  Hughs  Sketches  Out  Its  Superhub  Strategy,  PC  Week, 

March  21  1994  v1 1  n1 1  p47(1 ).  This  product  may  be  pertinent  to  study. 

•  ToUy,  Kevin,  and  Newman,  David,  High-end  Routers:  An  in-depth  Evaluation. 
Data  Communications,  December  1993  v22  n18  p68(12). 

•  Tolly,  Kevin,  Questioning  Performance,  Data  Communications,  April  1992, 
v21,  n6,  p39(2). 

•  Wallace,  Bob,  Hughs  to  Roll  Out  SNMP  Modules,  InfoWorld,  March  14  1994 
v16  n1 1  p3(1).  This  product  that  may  be  pertinent  to  study. 

•  Wexler,  Joanie  M.,  Router  vendors  vie  for  top  performance:  Cisco  slips  in 
some  categories  but  maintains  overall  consistency  across  various  protocols, 
Computerworld,  June  8  1992  v26  n23  p59(1).  Article  indicates  that  Harvard 
University  runs  independent  multiprotocol  bridge  /  router  throughput  tests 
annually  and  that  Scott  Bradner  is  a  full-time  consultant  to  Harvard. 

•  Wilson,  Jane,  Bridge  links  LANs  to  FDD!:  Fibermux's  Ethernet  bridge  has 
60,000-pps  speed,  InfoWorld,  Feb  8  1993  v15  n6  p30(1).  This  product  may 
be  pertinent  to  study. 

•  Wilson,  Jayne,  Bridging  router  has  100,000-pps  throughput,  InfoWorld,  March 
8 1993  v15  nIO  p38(1).  This  router  supports  FDDI  and  Ethernet  LANs. 
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5.3  Defense  Technical  Information  Center  (OTIC)  Search 

The  Defense  Technical  Information  Center  (DTIC)  search  was  performed  at  the 
DTIC  office  in  Los  Angeles  area  by  DTIC  personnel.  The  terms  listed  below  were 
searched  by  the  DTIC  computer.  Terms  that  were  used  to  conduct  this  search  included: 


Analog  Simulation 
Bridges 

Circuit  Interconnections 
Command  Contrd  Communications 
Computer  Communications 
Computer  Networks 
Computerized  Simulation 
Cryptography 
Data  Processing 
Delay  Circuits 
Delays 

Electric  Bridges 

Electronic  Mail 

Electronic  Security 

Impedance  Bridges 

Information  Systems 

Interconnect 

Interconnecting 

Interconnectors 

Layer 

Link 

Local  Area  Networks 

Network  Layer 

OSI  Security  Architecture 

Packet  Switching 

Protocol 

Relays 

Routers 


Bridge 

Capacitance  Bridges 

Command  And  Control  Systems 

Communications  Networks 

Computer  Gateways 

Computer  Viruses 

Conferencing  (Communications) 

Data  Links,  Delay 

Data  Transmission  Systems 

Delay  Lines 

Digital  Simulation 

Electric  Relays 

Electronic  Relays 

Hybrid  Simulation 

Information  Exchange 

Information  Transfer 

Interconnected 

Interconnector 

Interoperability 

Layers 

Links 

Microwave  Bridges 

Open  Systems  Interconnection 

OSI 

Polarized  Relays 
Protocols 
Router 
Routing 
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Secure  Communications 

Security 

StarKterds 

Time  Delay  Relays 

Wide  Area  Networks. 

The  results  of  the  DTIC  searches 
Secure  Solutions. 


Secure  Data 
Standards 

Tactical  Data  Systems 
Transport  Layer 

were  collected  into  a  bibliography  and  sent  to 
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5.4  Internet  Search 

The  Internet  was  searched  using  a  variety  of  methods,  including  file  transfer 
protocol  (FTP),  gopher,  world-wide-web  (WWW),  and  MOSAIC.  Searches  were 
conducted  using  keywords  such  as  OSI,  protocol,  communications,  network,  LAN, 
performance,  routers,  delay,  bridges,  etc.  Results  were  refined  with  the  knowledge  and 
expertise  gained  from  previous  searches. 

FTP  searches  involved  logging  into  known  locations  such  as:  ds.internic.net, 
ftp.sura.net,  nemo.ncsl.nist.gov,  ^.tis.com,  etc  and  then  searching  for  article  names 
that  fit  the  search  criteria.  This  search  was  utilized  when  a  document  or  previous 
search  results  from  other  methods  pointed  to  an  FTP  site  for  further  information. 

Gopher  searches  utilized  a  menu  and  keyword  search.  The  gopher  utility  is  an 
electronic  agent  that  communicates  with  other  gopher  agents  throughout  the  internet. 
The  gopher  server  displays  a  menu  of  services  it  knows  about  and  presents  these  for 
the  user  to  begin  a  search  for  items  of  interest.  Note  that  all  internet  resources  are 
available  to  gopher  sites  because  updated  information  must  be  added  to  the  gopher 
menu  system. 

The  WWW  is  a  hypertext  menu  system  for  user-friendly  traversing  through  the 
internet  and  connects  to  other  WWW  servers.  This  is  a  much  newer  technology,  so  only 
a  small  percentage  of  all  available  Internet  resources  are  catalogued.  Searches  were 
conducted  by  selecting  menu  items  related  to  the  keywords. 

To  extended  the  search  capabilities  within  WWW,  MOSAIC  was  used  in  later 
stages.  MOSAIC  is  an  x-windows  interface  to  WWW  which  provides  a  user-friendly 
interface  and  allows  searches  by  user-defined  keywords. 

In  addition  to  searching  the  Internet,  a  variety  of  special  interest  bulletin  board 
system's  (BBS's)  were  searched,  including  COMSEC,  dissp,  and  nist.  The  search  was 
performed  by  checking  message  sections,  file  names,  and  descriptions  using  the 
keyword  search  methodology. 

Finally,  E-mail  requests  were  sent  to  authors  and  selected  professors  to  assist  in 
our  search  by  requesting  applicable  information,  doctoral  research,  and  papers. 
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5.5  Vendor  Research 

Various  vendors  could  be  potentially  contacted  to  acquire  empirical  test  data 
relevant  to  this  study.  These  include  bridge  /  router  vendors,  embedded  COMSEC 
module  vendors,  OSI  host  /  workstation  vendors,  and  independent  test  laboratories. 

5.5.1  Bridge  /  Router  Vendors 

An  article  in  Systems  Integration  magazine  [ILIVI91]  contains  a  table  that 
identifies  vendors  (with  phone  numbers)  ttiat  manufacture  relays  (bridges,  routers  and 
brouters).  The  table  also  identifies  the  protocols  supported  by  these  relays  and  their 
“packet  forwarding  rates.”  The  inverse  of  the  packet  forwarding  rate  provides  an 
estimate  for  what  is  called  the  “processing  delay  through  relay”  in  this  report.  This  table 
could  be  used  to  identify  bridge  /  router  vendors  that  have  products  which  interconnect 
802.3  and  FDDI  LANs. 

5.5.2  Embedded  COMSEC  Module  Vendors 

The  processing  delay  associated  with  security  protocols  can  be  decomposed  into 
two  elements:  1)  the  delay  associated  witti  generating  clear  headers,  protected  headers 
and  padding,  and  2)  the  cryptographic  processing  associated  with  the  resultant  POU 
(excluding  the  clear  header).  The  processing  delay  associated  with  the  first  element  is 
much  like  the  delay  associated  with  general  communication  protocols  and  is  roughly 
proportional  to  the  size  of  the  headers.  The  processing  delay  associated  with  the 
second  element  is  proportional  to  the  size  of  the  overall  PDU,  excluding  the  clear 
header. 

Vendors  of  embedded  COMSEC  modules  can  be  contacted  to  determine 
estimates  for  the  delay  associated  with  using  these  modules  to  encrypt  PDUs  and  to 
compute  integrity  check  values  for  them.  This  would  provide  an  estimate  for  the  second 
timing  element  described  previously.  Although  an  FDDI  LAN  operates  at  a  nominal 
transmission  rate  of  100  Mbps,  this  does  not  mean  that  the  embedded  COMSEC 
module  will  have  to  operate  at  this  rate.  Since  an  FDDI  ring  network  can  support  up  to 
1000  stations  along  the  ring,  each  station  only  gets  a  small  percentage  of  time  to 
transmit  data.  Stations  will  therefore  have  time  (on  the  average)  to  encrypt  frames 
before  transmission  opportunities  arise.  Data  can  therefore  be  collected  for  COMSEC 
modules  that  operate  at  higher  data  rates  in  order  to  arrive  at  estimates  for  the 
cryptographic  processing  delays  associated  with  security  protocols. 

5.5.3  OSI  Host  /  Workstation  Vendors 

Vendors  of  OSI  host  /  workstation  products  can  be  contacted  to  determine  if  they 
have  estimates  for  the  delay  associated  with  processing  data  through  OSI  stacks  or 
processing  delays  for  individual  protocols. 


Secure  Solutions,  Inc. 


S-8 


Contract  No.  N00039-93-C-0099 


Demonstration  of  ConcofA  (DRAFT) 


Augusts.  1994 


5.5.4  Independent  Test  Laboratories 

Independent  test  laboratories  could  be  contacted  to  determine  if  they  have 
estimates  for  the  delays  associated  with  LAN  network  configurations  /  components  / 
individual  protocols.  Two  of  these  test  groups  are  the  Performance  Testing  Alliance  for 
Networks  (PTAN)  and  Benchmarking  Methodology  Working  Group  (BMWG). 

The  PTAN  was  formed  in  1990  by  a  group  of  vendors  and  users.  The  goal  of 
PTAN  is  to  "strive  for  consistent  results  In  testing  the  same  networking  devices, 
adapters  and  software." 

The  BMWG  Cambridge,  MA,  recommends  standards  for  the  Transmission 
Control  Protocol  /  Internet  Protocol  (TCP  /  IP)  community.  BMWG  is  formulating  the 
terminology  and  procedures  for  testing  network-connecting  devices  and  reporting  the 
test  results.  BMWG  is  a  unit  of  the  Internet  Engineering  Task  Force  (IETF). 

Scott  Bradner  chairs  both  the  PTAN's  bridges  and  routers  committee  and  the 
BMWG.  He  can  be  reached  at  10  Ware  Street.  Cambridge,  MA  02138,  (617)  495-3864. 
[LIVI91] 
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6.0  Conclusions  and  Recommendations 

This  section  contains  the  conclusions  and  recommendations  for  Task  1  of  this 
Phase  II  SBIR  effort. 

6.1  Conclusions 

Conclusions  regarding  the  impact  on  host-to-host  delivery  time  as  a  function  of 
where  security  protocols  are  placed  within  OSI  layers  are  as  follows: 

•  Providing  end-to-end  security  services,  as  opposed  to  link  security  services, 
improves  (reduces)  delivery  time  because  security  encapsulation  / 
decapsulation  functions  are  only  performed  at  the  source  and  destination 
host.  When  link  security  services  are  used,  security  encapsulation  / 
decapsulation  functions  are  performed  repeatedly,  thereby  increasing  the 
host-to-host  delivery  time  for  a  given  network  configuration. 

•  In  some  situations,  it  is  desirable  to  implement  security  services  within  relays 
(or  host  front  ends).  Implementation  of  security  protocols  at  lower  OSI  layers 
in  relays  (or  front  ends)  reduces  tiie  host-to-host  delivery  time  (in  qualitative 
terms),  since  fewer  headers  are  processed  within  them. 

6Ji  Recommendations 

The  following  recommendations  are  made  from  the  standpoint  of  the  delivery 
time  evaluation  factor: 

•  Whenever  possible,  the  Navy  should  provide  end-to-end  security  services  by 
implementing  security  protocols  at  the  top  of  layer  three  or  higher  within 
hosts.  This  will  minimize  the  host-to-host  delivery  time  in  comparison  to 
providing  link  security  services. 

•  The  results  of  this  task  should  be  factored  into  the  systems  /  security 
engineering  process  that  will  be  used  under  Task  4  of  this  effort  which  will 
define  Naval  requirements  for  secure  network  products. 
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